<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="content-type">
  <title>Config::System</title>
  <meta content="Ran Eilam" name="author">
</head>
<body>
Config::<br>
simple ones differ in format<br>
JSON<br>
IniFiles<br>
Dicop<br>
XML<br>
MRTG<br>
HtDig<br>
DotNetXML - in the manner of .Net<br>
General - has its own<br>
going up...<br>
Auto - magic unix file support<br>
Any - INI JSON Perl XML YAML<br>
Grammar - define your own domain specific configs <br>
Generic - add config schema<br>
Objective - objects everywhere<br>
Model - model it then autobuild UI on it<br>
some more focused only on accessing the config:<br>
Class - config methods<br>
Tie - easier to access<br>
CPAN easter egg:<br>
Thanks very much to: my wife Erika for neverending patience<br>
I'd like to thank my wife now<br>
and many more, and many embedded in larger packages.<br>
I don't have time to talk about the great features in some of these:<br>
include files<br>
Cascade<br>
inheritance between sections<br>
<br>
Hierarchical - validators, cascading with pretty printing of hierarchy<br>
<br>
in spirit of complex, BBCs:<br>
<br>
Config::Wrest - Read and write Configuration data With References,
Environment variables,
Sections,
and Templating<br>
templates!<br>
exec_1 : ~/bin/foo<br>
exec_2 : ~/bin/bar<br>
becomes:<br>
exec_dir: ~/bin<br>
exec_1&nbsp; : [% exec_dir %]/foo<br>
exec_2&nbsp; : [% exec_dir %]/bar<br>
and most of what we described so far<br>
<br>
on the other end of the spectrum...<br>
<br>
PBP way: Config::Std<br>
nice, clean<br>
only one with clearly defined list of error messages<br>
<br>
Scalar second argument to 'read_config' must be empty
<br>
<br>
You passed a scalar variable as the destination into <code>read_config()</code>
was supposed to load a configuration file, but that variable already
had a defined value, so <code>read_config()</code> couldn't autovivify
a new hash for you. Did you mean to pass the subroutine a hash instead
of a scalar?<br>
<br>
simple, weak<br>
but does not have complexity of Wrest which uses special chars- no need
for escaping<br>
<br>
many have not been updated this millenium<br>
<br>
many are representative of certain things Larry Wall said about CPAN in
Israel<br>
<br>
And a special mention to the obligatory Simple module, looks nice but
no simpler than others<br>
There is also Trivial<br>
it is not<br>
<br>
<br>
most expensive supermarket in israel is called hachi zol<br>
<br>
<br>
<br>
Merge, which we will get back to<br>
<br>
<br>
excellent example of word inflation:<br>
<br>
Trivial<br>
Tiny<br>
Simple<br>
Fast<br>
Auto<br>
General<br>
Objective<br>
Universal<br>
<br>
Like in alenby street red queen effect<br>
the config namespace is the alenby street of CPAN<br>
and the inflation is both ways<br>
<br>
BTW do we have a case here of NIH? but its not extreme disorder and
fragmentation<br>
it may not be more efficient to put them all together under unified
management<br>
they learn from each other<br>
<br>
<br>
also interesting to see how it relates to how they link to each other
in See Also<br>
<br>
<br>
<br>
basic sameness:<br>
load<br>
read_config 'demo2.cfg' =&gt; my %config;<br>
retreive<br>
$config_value = $config{Section_label}{key};<br>
distribute<br>
my_function($config_value);<br>
<br>
no answer to:<br>
accessing/distributing<br>
&nbsp;&nbsp;&nbsp; globals<br>
&nbsp;&nbsp;&nbsp; parameters<br>
&nbsp;&nbsp;&nbsp; instance data<br>
&nbsp;&nbsp;&nbsp; injections<br>
<br>
they are just stores, with various level of API iceness<br>
you always have to load, read, distribute<br>
except maybe Merge<br>
<br>
we need...<br>
config::PieceOfCakeInterDimensional<br>
does everything above, of course<br>
with options for ultra simple use ala Config::Std<br>
but focuses on uses cases:<br>
help me get my data from config file to those who need it<br>
avoid duplication<br>
why load and retrieve? just use a module and get it<br>
how is it best accessed?<br>
as package variables<br>
selfvars is in package vars<br>
&nbsp;&nbsp; <br>
<br>
Why configuration?<br>
invisible<br>
take it next level<br>
higher level<br>
use cases<br>
use lower level config system<br>
<br>
<br>
<h1>Using Config::System</h1>
<h3>the <font color="#999999"><i>invisible</i></font> configuration
module<br>
</h3>
<p>To use <code>Config::System</code>, you 1st make your application
classes
configurable, then create the required configuration files. Then you
can easily
access configuration data in code. This guide
explains these 3 steps for a simple example, and then shows some more
advanced uses.<br>
</p>
<h2>Simple Usage<br>
</h2>
<p>A class is configurable, if it declares, and maybe even uses,
configuration properties:</p>
<pre>package MyConfigurableClass;<br>use Moose;<br>use Config::System Verbose =&gt; {isa =&gt; 'Bool'};<br></pre>
<p><code>MyConfigurableClass</code> is now configurable. You can now
add the
property to a configuration file, and access it from code inside the
configurable class, as if it were a package variable:<br>
</p>
<pre>sub do_something { print "Verbose is $Verbose" }</pre>
<p>Note that <code>$Verbose</code> is exported into the
configurable class. It's
value may come
from a configuration file, a command line setting, a global
configuration store, or anywhere actually. The point is, that the
configurable class doesn't care. We will soon show how this is done.</p>
<p>By default, with no options given at all, the value will come from a
configuration file called <code>default.properties</code>, in the
current working
directory. The file uses <code>Config::Std</code> syntax:</p>
<pre>[MyConfigurableClass]<br>Verbose : 1</pre>
<p>Each configurable class implies a section with the same name. The
members of the section are the configurable properties of the class.<br>
</p>
<p>Note there was no need to load a configuration file, read it into
some data structure, and then distribute it to classes who may need it.
For the simple case, <code>Config::System</code> is almost invisible-
create a configuration file, make a class configurable, and the
properties are available as package variables.<br>
</p>
<p>These are the 3 steps we took:</p>
<ol>
  <li>Make the class configurable by defining a configuration property<br>
  </li>
  <li>Access the value from the configurable class as a package variable</li>
  <li>Place a value for the property in the default configuration file</li>
</ol>
<p>Now we can make sure it works, by running the command line:</p>
<pre>perl -MMyConfigurableClass -e 'MyConfigurableClass-&gt;do_something'</pre>
<p>Which should print:<br>
</p>
<pre>Verbose is 1<br></pre>
<br>
<h2>features</h2>
<ul>
  <li>invisible- no code to read the config file, no code to get a hash
and distribute different parts to different parts of the application.
Minimal centeralized configuration setup- it is classes that define
their configurable properties which is more modular<br>
  </li>
  <li>properties</li>
  <ul>
    <li>defaults</li>
  </ul>
  <ul>
    <li>expressions</li>
    <ul>
      <li>properties in same section don't need class prefix<br>
      </li>
    </ul>
  </ul>
  <ul>
    <li>memoized</li>
    <li>constraints</li>
    <li>cascade set</li>
  </ul>
  <li>accessing properties<br>
  </li>
  <ul>
    <li>dynamically scoped</li>
  </ul>
  <ul>
    <ul>
      <li>which allows for everything from simple singleton global
config to configuration scoped per user or directory</li>
    </ul>
  </ul>
  <ul>
    <li>easy access to store: Store() return an object where you can
get/set any property from any class</li>
    <li>declare globaly at top level the names of configuration files</li>
  </ul>
  <li>setting properties</li>
  <ul>
    <li>properties overridable from CLI</li>
    <li>configuration files are Config::Std syntax<br>
    </li>
  </ul>
  <li>TODO</li>
  <ul>
    <li>writing config file<br>
    </li>
  </ul>
</ul>
<br>
<br>
<h2><br>
</h2>
<h2><br>
</h2>
<h2>[TODO]</h2>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<h2>Making Classes Configurable</h2>
<h2>Making A Configuration File</h2>
<h2>More on Accessing Configuration Data</h2>
<h2>Using Expressions in Properties<br>
</h2>
<h2>Specifying Configuration Files</h2>
<h2>Overriding Properties from the Command Line</h2>
<pre><br></pre>
<h2>
</h2>
<br>
<p></p>
<ol>
  <li>use Config::System, and specify your configuration properties</li>
  <li>use the configurable properties as package scoped variables</li>
</ol>
<p>Once a class is configurable, it can have a section, named after the
configurable class name, in the configuration store. Which lets you add
this section to your configuration files, for example.<br>
</p>
Configuration properties are just like Moose attributes, in that
they have a name, type constraint, etc., but there are 2 differences:
<ol>
  <li>Unlike Moose attributes, configuration properties are not
attached to instances, though they could be. They could also be global
for all instances of a configurable class, or else there could be
several configuration stores. One for each public web directory in a
web server, for example. This is encapulsated in the configuration
access policy. Configurable classes only define the properties, not the
access policy.</li>
  <li>Unlike Moose attributes, which are accessed through accessor
methods, configuration properties are accessed from configurable class
code, through package scoped variables. From code in other places, they
can be accessed through methods of the configuration store, or as
package variables, from the configurable class.</li>
</ol>
<h2><br>
</h2>
<br>
<p>Once you have some configurable classes, you can create
configuration
files. By default, a property file called "default.properties" is
searched in the current working directory when the Perl script was run.
You can however use as many configuration files as you need, as will be
explained later.</p>
<p>The parsing is done using Config::Std, so it's the same syntax.</p>
<p>Sections are named after the Perl class that they configure. So for
the configurable class MyConfigurableClass above, you could add the
following section to the configuration file:</p>
<br>
<br>
<br>
<br>
<pre>perl -MMyConfigurableClass -e \<br>    'MyConfigurableClass-&gt;do_something' \<br>    -set MyConfigurableClass::Verbose=0<br><br></pre>
just replace<br>
with 'MooseX::Getopt';<br>
<br>
with<br>
with 'Config::System::MooseX::Getopt';<br>
<br>
and now you can set with -set Foo=1<br>
<br>
<br>
todo:<br>
allow more/other config files in options- optioal and required files<br>
add link_config options to get config from somewhere else<br>
todo: allow specifying config files on command line for moosexgetopt
role<br>
need global section<br>
aliases from cli to properties<br>
aliases for properties<br>
connections between properties<br>
<br>
todo: not lazy enough<br>
computing store loads config files<br>
should load them only on 1st access<br>
or maybe better load them as now<br>
but dont set_expression_1st on sections<br>
dont even create a section until it is needed<br>
when needed 1st, go through all config files looking for the section
and compile only the property you need<br>
this solves a major issue: all your classes will be loaded even if you
use 1 property<br>
skip feature from config merge, actuallymaybe build on top of config
merge<br>
todo:empty section is global<br>
todo: declare config and specify all pacakges that will have it as well<br>
or at some top class<br>
or make a package which gives you these as vars<br>
and the clients use it<br>
sharing properties with other classes<br>
<br>
<br>
http://search.cpan.org/src/HIO/Hash-Extract-0.01/t/01-basic.t making
hash into lexicals<br>
http://search.cpan.org/src/HIO/Devel-RunBlock-0.01/t/01-runblock.t for
running code inside a block, so return returns<br>
<br>
<br>
<br>
why is this needed<br>
look and copy:<br>
http://search.cpan.org/src/DRTECH/Config-Merge-1.00/examples/README<br>
<br>
<br>
<br>
# import the Store function to access the store<br>
use Config::System;<br>
<br>
# declare a class configurable<br>
use Config::System foo =&gt; {isa =&gt; 'Str'};<br>
<br>
<br>
checkout lexical::persistence and Pad::Tie<br>
<br>
<br>
<br>
todo: support no property descriptor:<br>
<br>
use Config::System [qw( foo bar )] =&gt; {};<br>
<br>
<br>
<br>
use MyConfig;<br>
get $Verbose<br>
<br>
<br>
mark property as strict or lazy for time of start of build for example<br>
<br>
<br>
<br>
add a mechanism to add functions with use to property expressions<br>
</body>
</html>
